home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 13575 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: ipx2.rz.uni-mannheim.de!mw
  2. From: mw@ipx2.rz.uni-mannheim.de (Marc Wachowitz)
  3. Newsgroups: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  4. Subject: Re: What Should An Exception Handling Do? -- Clarification of rules
  5. Followup-To: comp.object,comp.lang.eiffel,comp.lang.c++,comp.lang.beta,comp.lang.java,comp.lang.sather
  6. Date: 26 Mar 1996 15:59:09 GMT
  7. Organization: ---
  8. Message-ID: <4j948d$t3d@trumpet.uni-mannheim.de>
  9. References: <Doq3sv.MzA@research.att.com> <1996Mar25.160702.14229@schbbs.mot.com>
  10. NNTP-Posting-Host: ipx2.rz.uni-mannheim.de
  11. X-Newsreader: TIN [version 1.2 PL2]
  12.  
  13. David L. Shang (shang@corp.mot.com) wrote:
  14. > But an exception is not necessarily an error. Sometimes it is an
  15. > condition that requires some extraordinary computation, a condition
  16. > that is not supposed for a regular case, [...]
  17.  
  18. Let's look at the problem with fresh eyes, without thinking immediately
  19. about using the technical feature called "exception" in a few programming
  20. languages.
  21.  
  22. Some routine (often supposed to be reused for different contexts) wants
  23. the "advice" of its caller (or the caller's caller etc.) how to handle an
  24. unusual condition ("advice" might imply activities, like a user query).
  25.  
  26. To make this "advice" general, it should be some code supplied by the
  27. caller(s). Thus we need to somehow (see below) pass a routine to the
  28. given library routine; let's call this condition-handling routine the
  29. "handler".
  30.  
  31. Since the handler might have to act depending on local information in
  32. the call chain, it needs some way to access such information - which
  33. should be of no concern whatsoever to a library routine which encounters
  34. the condition. In object oriented languages, this means that a handler
  35. would in fact be the invocation of some object's method - thus any local
  36. differences of various handlers can be specified by deriving from some
  37. general handler (this may be by inheritance or delegation, depending which
  38. facilities are more appropriate for the given situation/language). In
  39. applicative languages like Lisp, Scheme or Dylan, you wouldn't even need
  40. objects with methods, but could alternatively just create a closure in
  41. the environment of the handler. (One might say that objects are the poor
  42. man's closures ;-)
  43.  
  44. The remaining question is how the library routine would know which handler
  45. it should use. Depending on the situation, one might choose an additional
  46. argument, or place it into some context data structure which is available
  47. anyway, or temporarily bind a globally visible variable to the handler
  48. while it's supposed to be active (and restore the previous handler after
  49. the scope of the local handler is left).
  50.  
  51. What the condition handling system of languages like Lisp and Dylan provides
  52. (in addition to the mechanism e.g. of C++) is an implicit management for
  53. the dynamic binding. If it's true that this style of handling is rare, it
  54. shouldn't be problematic to do this by yourself. If you find that you need
  55. it frequently, you can as well design some abstractions for this purpose.
  56.  
  57. Given that repairing a problematic condition requires much more knowledge -
  58. and a more intimate cooperation between the signaling routine and the
  59. handler - than merely receiving a failure notification, it doesn't appear
  60. too horrible that one needs to make it somewhat more explicit.
  61.  
  62. -- Marc Wachowitz <mw@ipx2.rz.uni-mannheim.de>
  63.